Virtual private networks (“VPNs”) allow users to connect from external networks to private networks safely and securely. To enable the secure connectivity, VPNs configure encrypted communications connections between user devices and the private networks. Because the connections are encrypted, data transmitted via the VPN tunnels is protected, and unauthorized individuals cannot eavesdrop on the transmitted traffic.
VPNs may be implemented using various security protocols. For example, some VPN tunnels are secured using Layer 3 protocols such as the Internet Protocol Security (“IPSec”) protocol. To secure the IP-based communications, IPSec configures authenticated communications sessions and encrypts each packet of the session. Some other VPN tunnels are Layer 2 VPN (“L2VPN”) tunnels and use the Generic Routing Encapsulation (“GRE”) and IPSec protocols to encrypt the exchanged packets. L2VPN connectivity allows extending the L2 networks from on-premise-datacenters to cloud-based computer networks. L2VPN networks may support the datacenter migration and may dynamically engage off-premise compute resources to meet fluctuating demand.
Some L2VPN tunnels include two layers of encapsulations: a GRE encapsulation and an Encapsulating Security Payload (“ESP”) encapsulation. GRE is a simple IP packet encapsulation protocol. GRE is used when IP packets need to be transmitted from one network to another without being parsed or treated like IP packets by the intervening routers.
ESP also encapsulates IP packets. However, it does that differently than GRE: unlike GRE, ESP applies cryptographic algorithms to contents of the packets so that the contents cannot be eavesdropped by the intervening routers. Applying the cryptographic algorithms to the contents may include scrambling the IP packets and transmitting the scrambled packets to a receiver. Since the transmitted packets are scrambled, the intervening routers cannot modify the contents of the packets.
However, encapsulating L2VPN packets with a GRE header and an ESP header may result in prepending more than 100 bytes of headers to the packets. Prepending that much data to each original Ethernet packet may cause the resulting packets to exceed a maximum packet size that intermediate devices are configured to handle.
Since a total length of each L2VPN packet should not exceed a certain length and since the GRE-ESP headers are usually long, the large packets need to be divided into small fragments, and the fragments need to be prepended with their own GRE-ESP headers. The process of dividing a packet into packet fragments is referred to as a packet fragmentation.
Original packets are usually divided into fragments by edge service gateways. As an edge service gateway divides an original packet into fragments, the gateway may determine a packet identifier for the packet. A packet identifier, also referred to herein as an Internet Protocol Identifier (“IPID”), is a packet sequence number that the gateway assigns to a detected packet. At first, the identifier is set to an initial value. Upon detecting a packet, the gateway increments the packet identifier by one, assigns the incremented identifier to the packet, divides the packet into fragments, and includes the identifier in the headers of the fragments. This is performed for all long packets. Once the identifier exceeds a certain limit, the identifier is reset to the initial value.
A typical field in a packet header that is used to store a packet identifier usually includes only 16 bits, and thus typical identifiers can range from zero to (216−1). Once the identifier reaches 216, the identifier needs to be reset to an initial value. However, such an identifier in today's fast computer networks need to be reset quite often. For example, if devices in a network are configured with a maximum transmission unit (“MTU”) of 1500, wherein a MTU corresponds to a maximum size of packets that the devices may handle, if a combined GRE and ESP header is 100-byte-long, and if a 10 G uplink is configured to handle 800 k of packets having 1500 MTU per second, then a 16-bit-long identifier will be reset about 800 k/216 times per second, which is about 10 times per second.
Resetting a packet identifier, also referred to as an identifier wrapping, may have negative consequences on reliability of a network, especially on correctness of the packets that an edge service gateway assembles from the detected packet fragments. When an edge service gateway detects packet fragments, it relies on the packet identifiers associated with the fragments to assemble the fragments into the original packets. However, in fast L2VPN networks, the gateway often receives fragments that have the same packet identifier, but that actually belong to different original packets. For example, when the L2VPN network transmits the fragments from a sender to the receiver very fast, some of the received fragments with a particular identifier may belong to a first original packet, while other fragments with the same particular identifier may belong to a second original packet. This may happen when the sender resets the identifier before the receiver assembles the first original packet.
This problem is referred to as an incorrect splicing, IPID overflow, or mis-associating the packet identifiers to packet fragments, and has been described, for example, in U.S. patent application Ser. No. 16/232,887, entitled “Mechanisms for Preventing IPID Overflow in Computer Networks,” which is incorporated herein by reference in its entirety.